home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / networking / terms / kermit / b / k11f85.rno < prev    next >
Encoding:
Text File  |  1989-06-12  |  18.2 KB  |  387 lines
  1. .rm 66
  2. .c;Kermit - A Protocol for Painless Micro and Mini File Transfer
  3. .s 4
  4. .c;Brian Nelson
  5. .c;Computer Services
  6. .c;University of Toledo
  7. .c;2801 West Bancroft
  8. .c;Toledo, Ohio 43606
  9. .s 3
  10. Abstract
  11. .s 1
  12. This article will describe the Kermit
  13. file transfer protocol.
  14. This protocol allows many (if not most) types of computer
  15. systems to effect, at minimum, error free file transfer with other systems
  16. and microcomputers over asynchronous lines.
  17. .s 1
  18. Introduction
  19. .s 1
  20. With the widespread use of personal computers the need for file exchange
  21. between systems has become of foremost concern among users and managers alike.
  22. There are many commercial products available which meet this need, some of
  23. which may offer more advanced functions such as transparent
  24. record oriented file access. Networks that do this, such as DECnet,
  25. can be expensive, and if your computer or microcomputer is not on the
  26. network your needs won't be met. Transfer of files with removable disks
  27. can work, but generally only when the computers are of the same type, it's
  28. not very useful when the systems are removed in location. Rarely will
  29. a larger mini or supermini be able to read a microcomputer's disk.
  30. .s 1
  31. A more realistic approach, from both cost and convenience, is to find
  32. a way to use ordinary telecommunications and/or in-house PBX systems
  33. to connect computers and microcomputers together. If a local connection
  34. using a PBX or front end switch is not available, there is always dialup
  35. access with standard 103/212 modems.
  36. Data can be transferred with very simple methods, such as TYPING a file
  37. on one system and capturing it on the other system, but this gives no
  38. protection from noise and overrun of data. It is not very user friendly
  39. either. What is really needed is a protocol to accomplish file transfer
  40. reliably and efficiently.
  41. .s 1
  42. The first obvious use of any program or protocol designed to accomplish
  43. file transfer is to be able to provide the
  44. ability to support file uploads and downloads from minis and superminis such
  45. as the VAX and PDP-11 to remote personal computers, such as the PC and Rainbow.
  46. It should also be widely available for many different micros and mainframes.
  47. File transfer from micro to micro, as well as from a larger central host,
  48. should be possible. The command interface should be easy to learn, and
  49. require no intervention from a central site operator or other user.
  50. The many implementations of Kermit follow these lines, and all versions
  51. allow some form of transfer in either direction. More advanced versions,
  52. such as those found on the PDP-11, DEC10/20 and VAX, offer what is known
  53. as server operation, which allow the remote (connected) Kermit system to
  54. completely control the file exchanges from their system.
  55. Since as of this writing (October 9, 1985)
  56. there are available over 160 versions of Kermit available for numerous
  57. micro, mini and mainframe configurations, Kermit addresses this need
  58. quite well.
  59. .s 1
  60. While the primary use of Kermit will likely be to support file transfer
  61. from microcomputer to mini/supermini and mainframe connections, there
  62. are many uses for Kermit for connections from mini to mini and so on.
  63. The author routinely use Kermit
  64. for transfering software developed for the PRO/350 on a RSTS/E 11/23+ and
  65. a VAX 11/785, as well as using the PDP and VAX for dialing out to other
  66. systems around the country (not to mention VAX to PDP directly though
  67. a front end port selector).
  68. .s 1
  69. The Kermit protocol
  70. .s 1
  71. The Kermit protocol is designed to operate over normal asynchronous terminal
  72. lines. All data and commands are transferred with a packet oriented protocol,
  73. basically consisting of a start of packet character (normally SOH), followed
  74. by length, control, data and checksum fields.
  75. Communication is half duplex, in that for every packet sent, the sender
  76. must wait for either an acknowledgement packet (ACK) or a negative
  77. acknowledgement packet (NAK). Transmission is in ascii, with no requirements
  78. for the transmission of eight bit characters or control characters
  79. other than control-A for marking the start of a packet.
  80. All 'control' characters imbedded in the data are prefixed to convert them
  81. to printable characters, the same applying to eight bit characters if
  82. required by the characteristics of the line.  Since there are many
  83. different implementations of Kermit, the protocol provides a mechanism
  84. by which the capabilities of two connected Kermits can be negotiated to
  85. allow for differences in the level of protocol support.  Examples of
  86. protocol features that not all Kermits understand include data
  87. compression and transfer of file attributes.
  88. .s 1
  89. The packet format is
  90. .s 1
  91. .lit
  92.  
  93.     +------+-----------+-----------+------+------------+-------+
  94.     | MARK | char(LEN) | char(SEQ) | TYPE |    DATA    | CHECK |
  95.     +------+-----------+-----------+------+------------+-------+
  96.  
  97.  
  98. .eli
  99. where all fields consist of ASCII characters, and the char function converts
  100. a number in the range 0-94 (10)  to a printable ASCII character by adding
  101. 32 (10). The MARK, LEN, SEQ and TYPE fields are one byte, the DATA field
  102. is variable in size, and the CHECK field is one to three bytes in size.
  103. .br
  104. The MARK (normally control A) signifies the start of a packet. The length
  105. field tells how long the rest of the packet is. The SEQ field is used to
  106. insure synchronization used to detect lost or duplicate packets. The SEQ
  107. number wraps around every 64 packets due to the need to encode it as a
  108. printable ascii character in the range 32 (10) to 126 (10). The
  109. TYPE field specifies whether the packet is a DATA or CONTROL packet. The
  110. DATA section is used for the actual transfer of data or informative messages
  111. from a Kermit server, this field can be up to 90 characters in length.
  112. Any character whose low seven bits fall in the range of 0 to 37 (8),
  113. ie, char and 177 (8) is less than 40 (8), will have the value
  114. 100 (8) exclusive or'ed (xor'ed) with itself and be prefixed by a shift 
  115. character, '_#'. Other shift
  116. characters may be use for eight bit characters if the line characteristics
  117. require such. Data compression may also occur in the data field, this is
  118. done with yet another shift code and byte count sequence.
  119. The CHECK field is a checksum, either a one character, two character or
  120. three character CRC check; the sender computes it and the receiver must
  121. compute it and compare. A checksum mismatch will result in the receiver
  122. sending a NAK packet (negative acknowledgment) which directs the sender to
  123. resend the NAK'ed packet. The packet may be following by
  124. a terminator (likely an ascii 13). This terminator is NOT part of the
  125. protocol and is sent only to tell the receiver that a 'line' is present.
  126. Not all Kermit implementations require this; all Kermits will discard data
  127. outside of a packet in any event.
  128. .s 1
  129. Error detection and recovery is by checksum, as noted, and by packet
  130. read timeouts. If the packet should be corrupted the checksum will be
  131. incorrect, the receiver will NAK the packet.
  132. If an expected packet never arrives within the timeout period, or if the
  133. received packet is not the expected one (as determined by the SEQ field)
  134. the packet will also be NAK'ed. There are limits as to how many times
  135. an expected packet will be NAK'ed without aborting the current operation.
  136. .s 1
  137. Packet types
  138. .s 1
  139. .lit
  140.     D    Data
  141.     Y    Acknowledgement (ACK), text may be in DATA field
  142.     N    Negative Acknowledgement (NAK)
  143.     S    Send initiate (Send-Init)
  144.     R    Receive Initiate
  145.     B    Break (EOT, end of transmission)
  146.     F    File name header
  147.     Z    End of file (EOF, end of current file)
  148.     E    Error packet, text may be present in DATA field
  149.  
  150.     G    Generic SERVER command.  The first character in the
  151.         data field will be a command to a server, arguments
  152.         may follow that character.
  153.  
  154.        I    Login, user and password follow in data field
  155.        C    CWD, change working or default directory.
  156.        L    Bye, Logout server
  157.        F    Finish, Exit server, but do not log out
  158.        E    Erase, delete files on server system
  159.        D    Directory query
  160.        U    Disk space usage query
  161.        T    Type a file onto local kermit
  162.        R    Rename file(s) on server system
  163.        K    Copy file(s) on server system
  164.        W    Who's logged in, as in sho sys, sy/s, dev tt
  165.        M    Send a terminal message to a user
  166.        H    Help, the server responds with commands it can do
  167.        Q    Server status query
  168.        P    Program, run a program
  169.        J    Journal
  170.        V    Variable, alter a Kermit setting
  171.  
  172.     C    Execute host command. The host command follows in
  173.         the data field.
  174.  
  175. .eli
  176. Note that some of the generic server commands, as well as the C packet,
  177. may not be feasible for a given environment. For instance, the REMOTE LOGIN
  178. command, which sends the generic I command to the server, can only be done
  179. under RSTS/E; the generic U command (disk space) is meaningless under RSX
  180. unless one wants the free space on the entire volume. No Kermit server will
  181. abort on receiving a packet it can't execute, it will simply send an error
  182. packet with an informative message saying it can't process the requested
  183. function.
  184. .s 2
  185. A typical transaction
  186. .s 1
  187. An example of a Kermit-11 kermit telling a VMS Kermit-32 server to
  188. expect a file follows. The Kermit-11 command was SEND JUNK.TST
  189. .s 1
  190. .lit
  191.     (0)PDP sends:    ^A. S~* @-#Y3~( ,
  192.     (0)VAX sends:    ^A, Yp/ @-#Y3~!
  193.     (1)PDP sends:    ^A-!FJUNK.TST,-4
  194.     (1)VAX sends:    ^A%!Y,\I
  195.     (2)PDP sends:    ^A`"D$ set ter/vt100#M#J$ xcc :== ccl cc
  196.             #M#J$ xas :== ccl as#M#J!4S
  197.     (2)VAX sends:    ^A%"Y.5!
  198.     (3)PDP sends:    ^A%#Z,X"
  199.     (3)VAX sends:    ^A%#Y/R9
  200.     (4)PDP sends:    ^A%$B!_#
  201.     (4)VAX sends:    ^A%$Y+&1
  202.  
  203. .eli
  204. In packet zero, the Kermit's exchanged information regarding their
  205. capabilities. The PDP-11 sent an 'S' packet with the data for its
  206. maximum packet length, default time out, number of pad characters to
  207. follow a packet (none, hence the space), use a null for padding, end
  208. of line terminator (a CR + 32), the prefix character for control characters,
  209. a 'YES' to say the it can prefix eight bit characters with the default,
  210. that it would like to use CRC block checks, that it will use a tilde for
  211. data compression, and the 'CAPAS' mask, which here says that it can process
  212. attribute packets (discussed later).
  213. Since the VAX also sends a '3' for the checksum type, they will both switch
  214. to CRC checks on the following packets.
  215. In packet 1, the PDP11 sends the filename the VAX should use
  216. for the file it creates. The VAX then sends the acknowledgement. In packet
  217. three, the PDP sends the first (and only for this file) packet of data. Note
  218. that the sequence _#M_#J is a carriage return/line feed sequence with 100 (8)
  219. xored into each character. The '_#' character informs the other Kermit that it
  220. must xor the next character with 100 (8). In packet three the PDP11 sends
  221. an EOF packet, the VAX acks it. In packet four, the PDP sends a break packet
  222. which tell the VAX that no more files (of a possibly wildcard group) are
  223. coming and the VAX Kermit acks the break packet.
  224. Both Kermits now switch to the single character checksum and the
  225. VMS kermit enters the server idle state.
  226. .s 1
  227. More specific information regarding Kermit packets and state transitions can
  228. be found in the references listed at the end of the article.
  229. .s 2
  230. Transmission of file attributes
  231. .s 1
  232. One of the optional features of the Kermit protocol is the ATTRIBUTE packet.
  233. The attribute packets allow a Kermit program to send to a receiving Kermit
  234. information regarding the file organization, size, cluster/retrieval size,
  235. protection and so forth. There is even a system dependant attribute packet type
  236. that can be used to transfer things like the RMS11 IFAB 
  237. (the RMS/FCS attributes).
  238. Since to date only the author's Kermit implementation, Kermit-11, can process
  239. attribute packets, the discussion is limited to the PDP-11.
  240. .s 1
  241. One of the things that two Kermits exchange
  242. before any file transfer is an information packet, this packet tells the
  243. receiving Kermit about itself. The last field in this packet, the CAPAS mask,
  244. tells Kermit if the other one can process attribute packets. If two Kermit-11's
  245. are communicating, they will find that each can do so, and the sender of a file
  246. will then send over attribute packets indicating the need (or lack of)
  247. for binary transmission, based on the file organization, filetype and protection
  248. code (for RSTS/E).
  249.  If the sending Kermit-11 is running on RSTS/E, RSX11M/M+ or P/OS
  250. it will also send a copy of the RMS/FCS attributes so the received file will
  251. be identical (to FCS and/or RMS) to the copy on the sender's system. Since
  252. other implementations of Kermit may use this special system attribute packet,
  253. Kermit-11 always sends an attribute packet telling the receiver what hardware
  254. and operating system it is running on, and thus will only use such data if
  255. they are compatible.
  256. Of course, there will be times when a file may be binary and Kermit-11 can't
  257. tell so, many Kermit's have a SET FILE BINARY and SET FILE ASCII to allow the
  258. user to override defaults. Kermit-11 also has a SET FILE AUTO/NOAUTO to disable
  259. it from trying to determine a file's binary status.
  260. .s 1
  261. The PDP-11 Kermit-11 implementation
  262. .s 1
  263. The author's version of Kermit-11 is written in Macro-11 and can run on
  264. RSTS/E, RSX11M, RSX11M Plus, P/OS, RT11 and TSX+.
  265. This version of Kermit is distinct from the other three PDP-11 Kermits
  266. available; the Stevens P/OS menu driven Kermit; the University of Toronto
  267. RT11 pascal Kermit and Bob Denny's P/OS Kermit.
  268. In Kermit-11, the RSTS and RSX file system
  269. interface is via RMS11 version 2, while the RT11 interface attempts to
  270. emulate the RMS11 subsystem. The choice of Macro-11 for the implementation
  271. language was made for several reasons, one being the availability of the
  272. assembler on all systems and another being speed and compactness of the
  273. code.
  274. .br
  275. RMS11 was used for RSTS/E and the RSX11M based systems
  276. to provide a common i/o interface to
  277. the host file system. Additionally, Bob Denny of Alisa Systems further
  278. extended the RMS interface to support remote file access over DECNET with
  279. Kermit, allowing commands such as SEND NODENAME::[BRIAN.FUBAR]FILE.TYPE
  280. and other remote file accesses over DECNET. RMS11 version 2 also provides a very
  281. simple and powerful means of doing wildcard searching, file renames and
  282. file deletion via the $PARSE, $SEARCH, $RENAME and $DELETE
  283. macros; it also allows the same RMS interface
  284. code to be used on all systems without
  285. change.
  286. Points against RMS basically amount to it's size, RMS is quite
  287. large even if overlayed. This is helped by using the segmented RMSRES
  288. available on RSTS/E and RSX11M Plus. The one over negative point is that
  289. RMS11 version 2 does not function well, if at all, on the older versions
  290. of PDP-11 operating systems, specifically, one should be using RSTS/E v8
  291. or later, RSX11M v4.1 or later, and RSX11M Plus version 2.1 or later.
  292. .s 1
  293. All versions of Kermit-11
  294. receive eight bit data assuming no parity is used. Where parity is a must,
  295. Kermit-11 has to use a prefixing scheme for eight bit binary data.
  296. Binary files are created as FIXED no carriage control files
  297. such as used for task images. Note that parity generation is done by software
  298. in Kermit-11. The P/OS version of Kermit-11 runs under control of DCL. 
  299. The next release
  300. of Kermit-11, which will be 2.37, will include support for the PRO TMS
  301. (Telephone Management System) option.
  302. Each version of Kermit-11 has it's own source file
  303. to deal with the operating system, for RSX it is K11M41.MAC, for RSTS/E they
  304. are K11E80.MAC and K1180S.MAC, and for RT11 they are called K11RT*.MAC.
  305. Apart from these specific files, all other source
  306. files are shared. The RT11 Kermit-11 can use either the version 5.x XL and
  307. XC handler for high throughput, or it can use multiple terminal service to do
  308. all its terminal i/o. This second option allows the use of any
  309. interface supported,
  310. including the PDT150 modem port, DL/DLV11's and DZ/DZV11's.
  311. TSX+ users can connect to CL: for dialing out, the exact means is documented
  312. in the Kermit-11 users guide.
  313. .s 1
  314. Future directions
  315. .s 1
  316. With the advent of packet switched networks and satellite communications
  317. the Kermit protocol will likely be extended to increase efficiency over
  318. such links. The main problem is the half duplex nature of Kermit, the
  319. packet acknowledgements can take up to several seconds in transit thus
  320. drastically reducing the throughput. There are several possibilities under
  321. discussion and a standard should be appearing shortly.
  322. .s 2
  323. Summary
  324. .s 1
  325. With the knowledge that
  326. there are Kermit implementations for most personal computers in use
  327. it becomes apparent that the Kermit standard is well worth looking in to.
  328. A list of versions running
  329. on Digital hardware follows the article.
  330. .lit
  331.  
  332.  
  333. Kermit: A File-transfer Protocol for Universities 
  334. Frank da Cruz and Bill Catchings
  335. BYTE Magazine, June/July 1984
  336.  
  337. The Kermit Protocol Manual, version 5
  338. Frank da Cruz   April 1984
  339. Columbia University Center for Computing Activities
  340.  
  341. Information on obtaining Kermit:
  342.  
  343. KERMIT Distribution
  344. Columbia University Center for Computing Activities 
  345. 7th Floor, Watson Laboratory
  346. 612 West 115th Street
  347. New York, N.Y.  10025
  348.  
  349. Kermit is also usually found on the Decus symposia SIG tapes.
  350. Kermit-11 is available from DECUS as number 11-731
  351.  
  352. Digital hardware that Kermit is currently available for:
  353.  
  354.          Operating  Program   
  355. Machine          System     Language     Contributor
  356.      
  357. DEC PDP-11       MUMPS-11   MUMPS-1982   Cornell U
  358. DEC PDP-11       RSTS/E     Macro-11     U of Toledo
  359. DEC PDP-11       RSX-11/M   Macro-11     U of Toledo
  360. DEC PDP-11       RSX-11/M+  Macro-11     U of Toledo
  361. DEC PDP-11       RT-11      Macro-11     U of Toledo
  362. DEC PDP-11       RT-11      OMSI Pascal  U of Toronto
  363. DEC PDP-11       TSX+       Macro-11     U of Toledo
  364. DEC PDP-11       Unix 2xBSD C            Columbia U
  365. DEC PDP-11, ...  Unix V7    C            Columbia U
  366. DEC PDP-8        OS8, RTS8  PAL-8        R. Hippe
  367. DEC Pro-3xx      P/OS       Bliss, Macro Stevens I.T.
  368. DEC Pro-3xx      P/OS       Macro-11     U of Toledo
  369. DEC Pro-3xx      Pro/RT     Macro-11     U of Toledo
  370. DEC Pro-3xx      Venix V1   C            Columbia U
  371. DEC Pro-3xx      Venix V2   C            Columbia U
  372. DEC Rainbow      CPM86      ASM86        Columbia U
  373. DEC Rainbow      MS-DOS     MASM         Columbia U
  374. DEC Rainbow      QNX 1.x    C            Merrell-Dow
  375. DEC VAX          Ultrix-32  C            Columbia U
  376. DEC VAX          VMS        Bliss,Macro  Stevens I.T.
  377. DEC VAX          VMS        C (VAX-11 C) Columbia U
  378. DEC VAX          VMS        Pascal       U of Toronto
  379. DEC VAX, ...     Unix 4xBSD C            Columbia U
  380. DEC VT-180 Robin CPM80      Turbo Pascal Jeff Duncan
  381. DEC VT-180 Robin CPM80 2.2  M80,LASM     ACC
  382. DECmate-II,III   CPM80 2.2  M80,LASM     ACC
  383. DECsystem-10     TOPS-10    Bliss, Macro Stevens I.T.
  384. DECSYSTEM-20     TOPS-20    MACRO-20     Columbia U
  385.      
  386. .eli
  387.